Особенности работы системы при гранулярном управлении доступом

Особенности работы привилегий

Особенности работы привилегий

Привилегии

Особенности работы привилегий

  • Print Servers - Read

  • Event Log Servers - Read

  • Event Registration Rules - Add

  • Monitoring Servers - Read

  • Installation Servers - Read

  • Repository Servers - Read

  • DHCP - Read

  • File Servers - Read

  • Domain Controllers - Read

  • Group Policies - Read

  • Software Policies - Read

  • Automation Task Attributes - Manage

  • Automation Tasks - Manage

Привилегии позволяют видеть в базе данных автора изменений для ГП, политик ПО, заданий автоматизации, правил сбора событий и серверных подсистем (DHCP, серверы печати и т.д.)

  • Computers - Read

Привилегия позволяет видеть в базе данных информацию об установленных на компьютер подсистемах

  • Users - Return from trash

Для успешной активации роль с данной привилегией должна быть назначена на корень домена (при этом признак «Включая дочерние подразделения» может быть как установлен, так и не установлен)

  • Users and Groups Settings - Manage

Роль с данной привилегией должна быть привязана к корню домена с установленным признаком «Включая дочерние подразделения»

  • Users - Read

Привилегия дает права на чтение дополнительных атрибутов пользователей только через API и в базе данных.

Для чтения дополнительных атрибутов пользователей через интерфейс ALD Pro (вкладка «Дополнительные сведения» карточки пользователя) необходимы две привилегии:

  • Users - Read

  • Users and Groups Settings - Read

  • Computers - Remote access

До версии 2.4.0 привилегия распространялась на весь домен. С 2.4.0 привилегия имеет привязку к подразделению

  • SUDO Rules - Modify

Для возможности назначения правила SUDO на всех пользователей домена при выборе пункта «Любой пользователь» на вкладке «Пользователи» необходимо, чтобы привилегия входила в роль, которая привязана к корню домена с активным признаком «Включая дочерние подразделения».

Для возможности назначения правила SUDO на все компьютеры домена при выборе пункта «Любой компьютер» на вкладке «Компьютеры» необходимо, чтобы привилегия входила в роль, которая привязана к корню домена с активным признаком «Включая дочерние подразделения»

  • HBAC Rules - Modify

Для возможности назначения правила HBAC на всех пользователей домена при выборе пункта «Любой пользователь» на вкладке «Пользователи» необходимо, чтобы привилегия входила в роль, которая привязана к корню домена с активным признаком «Включая дочерние подразделения».

Для возможности назначения правила HBAC на все компьютеры домена при выборе пункта «Любой компьютер» на вкладке «Компьютеры» необходимо, чтобы привилегия входила в роль, которая привязана к корню домена с активным признаком «Включая дочерние подразделения».

Особенности работы методов PUT и PATCH

При работе этих методов могут не возвращаться ошибки об отсутствии прав на операции изменения сущностей.

При методах PUT и PATCH привилегия работает следующим образом:

  1. выполняется метод GET, который возвращает сущность в текущем состоянии;

  2. выполняется метод PUT или PATCH, который меняет сущность;

  3. выполняется метод GET, который возвращает измененную сущность.

Если отправлять PUT или PATCH запрос с телом запроса без изменения сущности, выполняется 1-й шаг - метод GET, который возвращает сущность в текущем состоянии, а метод PUT (2-й шаг) не выполняется, так как запись не меняется.

В этом случае пользователю без прав на изменение сущности (методами PUT или PATCH) системой не будет выдана ошибка об отсутствии прав на операцию, т.к. эта операция не выполнялась.

Если отправить PUT или PATCH запрос с изменением от пользователя, не имеющим на это права, валидация прав отработает корректно.

Возможные ответы системы на запросы GET при отсутствии прав на выполнение операции

При отсутствии прав на запросы GET система может выдавать следующие варианты ответов:

  • сообщение об ошибке на выполнение операции из-за отсутствия прав:

// {
    "error": "Отсутствуют права на выполнение данной операции",
    "success": false,
    "code": "ForbiddenError"
}

// {
    "error": "Отсутствуют права на выполнение данной операции",
    "success": false,
    "code": "DeniedIPAError"
}

  • успех операции с пустыми списками, для которых указано ненулевое количество записей:

// {    "data": [],    "total": 45,    "success": true}

  • успех операции с пустыми списками, для которых возвращается ноль записей:

// {    "data": [],    "total": 0,    "success": true}

Модель разграничения доступа на уровне атрибутов

В рамках конфигурации службы каталогов реализована модель разграничения доступа, которая предоставляет возможность просмотра ограниченного набора атрибутов пользовательских учётных записей без применения дополнительных ограничивающих политик. Данное поведение соответствует спецификации продукта и обеспечивает базовую функциональность каталога.

Аутентифицированным пользователям предоставлены права на выполнение операций чтения, сравнения и поиска по определённому набору атрибутов записей, принадлежащих классу posixAccount, который присваивается пользовательским учетным записям по умолчанию. В пределах контейнера cn=users предоставлен доступ к следующим атрибутам записи:

audio, businesscategory, carlicense, departmentnumber, destinationindicator, employeenumber, employeetype, facsimiletelephonenumber, homephone, homepostaladdress, inetuserhttpurl, inetuserstatus, internationalisdnnumber, ipacertmapdata, jpegphoto, l, labeleduri, mail, mobile, o, ou, pager, photo, physicaldeliveryofficename, postaladdress, postalcode, postofficebox, preferreddeliverymethod, preferredlanguage, registeredaddress, roomnumber, secretary, seealso, st, street, telephonenumber, teletexterminalidentifier, telexnumber, usercertificate, usersmimecertificate, x121address, x500uniqueidentifier, ipasshpubkey, ipauniqueid, ipauserauthtype, userclass, krbcanonicalname, krblastpwdchange, krbpasswordexpiration, krbprincipalaliases, krbprincipalexpiration, krbprincipalname, krbprincipaltype, nsaccountlock, memberof, rbtamiddlename, rbtadp, c

В пределах домена (dc=example,dc=ru) для атрибута altSecurityIdentities установлены права на чтение, сравнение и поиск аутентифицированным пользователям.

В пределах контейнера cn=accounts аутентифицированным пользователям разрешено выполнять операции поиска для проверки наличия значений у атрибутов userPassword и krbPrincipalKey. Важно отметить, что данная инструкция не предоставляет доступа к самим значениям указанных атрибутов, но позволяет установить факт их наличия в записи.

Для обеспечения базовой идентификации пользователей и корректного функционирования системных служб предусмотрен анонимный доступ на чтение к ограниченному перечню атрибутов записей класса posixAccount в контейнере cn=users. Атрибуты, доступные для анонимного просмотра, включают:

cn, createTimestamp, description, displayName, entryUSN, gecos, gidNumber, givenName, homeDirectory, initials, ipantSecurityIdentifier, loginShell, manager, modifyTimestamp, objectClass, sn, title, uid, uidNumber, rbtaou

В рамках политики управления учётными записями реализован комплекс правил контроля доступа, позволяющих пользователям самостоятельно администрировать определённые атрибуты собственных записей. Данный функционал соответствует принципам децентрализованного управления и снижает операционную нагрузку на администраторов службы каталогов:

  • В пределах контейнера cn=users аутентифицированным пользователям делегированы права на изменение параметров сценариев входа, профилей пользователей и параметров домашних каталогов, включая атрибуты ipantlogonscript, ipantprofilepath, ipanthomedirectory и ipanthomedirectorydrive;

  • В пределах контейнера cn=accounts реализовано право выполнения операции самостоятельной смены ipaProtectedOperation и write_keys;

  • В пределах домена (dc=example, dc=ru) установлен расширенный набор правил самостоятельного управления:

    • Пользователям предоставлена возможность самостоятельного создания и управления OTP-токенами в специализированном контейнере cn=otp. Правило применяется исключительно к объектам класса ipaToken и требует двойной привязки — пользователь должен одновременно являться владельцем и администратором токена.

    • Управление атрибутом epwd, включая операции добавления и модификации;

    • Операции модификации сертификатов X.509;

    • Делегированы права управления открытыми ключами SSH через атрибут ipasshpubkey;

    • Обеспечена возможность самостоятельного обновления контактной информации через модификацию атрибута mobile;

    • Реализовано правило изменения пароля и ключа аутентификации, включая userPassword, krbPrincipalKey, а также пароли Samba в различных форматах (sambalmpassword, sambantpassword);

    • Предоставлены права на чтение, поиск и сравнение атрибутов с префиксом x-ald-, что позволяет осуществлять указанные операции с данными мандатного управления доступом (МРД) собственной учётной записи.

Данный набор политик формирует целостную систему управления, обеспечивая баланс между функциональностью и требованиями безопасности службы каталогов. Все правила построены по принципу минимальных привилегий и ограничены контекстом собственной учётной записи, что исключает возможность несанкционированного доступа к изменению данных других пользователей.